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Foreword 

This Technical Specification (TS) has been produced by Joint Technical Conmiittee (JTC) Broadcast of the European 
Broadcasting Union (EBU), Comite Europeen de Normalisation ELECtrotechnique (CENELEC) and the European 
Telecommunications Standards Institute (ETSI). 

Please note that the present document is a revision to TR 102 542 [i.l], and has been converted to a TS because the 
language used in the document is akin to that of a TS. 

NOTE: The EBU/ETSI JTC Broadcast was established in 1990 to co-ordinate the drafting of standards in the 
specific field of broadcasting and related fields. Since 1995 the JTC Broadcast became a tripartite body 
by including in the Memorandum of Understanding also CENELEC, which is responsible for the 
standardization of radio and television receivers. The EBU is a professional association of broadcasting 
organizations whose work includes the co-ordination of its members' activities in the technical, legal, 
programme-making and programme-exchange domains. The EBU has active members in about 
60 countries in the European broadcasting area; its headquarters is in Geneva. 

European Broadcasting Union 

CH-1218 GRAND SACONNEX (Geneva) 

Switzerland 

Tel: +41 22 717 21 11 

Fax: +4122 717 24 81 

The Digital Video Broadcasting Project (DVB) is an industry-led consortium of broadcasters, manufacturers, network 
operators, software developers, regulatory bodies, content owners and others committed to designing global standards 
for the delivery of digital television and data services. DVB fosters market driven solutions that meet the needs and 
economic circumstances of broadcast industry stakeholders and consumers. DVB standards cover all aspects of digital 
television from transmission through interfacing, conditional access and interactivity for digital video, audio and data. 
The consortium came together in 1993 to provide global standardisation, interoperability and future proof 
specifications. 

The present document is part 3, sub-part 3 of a multi-part deliverable full details of the entire series can be found in 
partl,TS 102 542-1 [i.2]. 
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Scope 



The present document is designed as a companion document to help implement the DVB -IPX V Phase 1 version 4: 
Transport of MPEG2-TS Based DVB Services over IP Based Networks [1], which is referred to as the Handbook. 

Part 3 of this multi-part deliverable deals with Error recovery technologies. The present document provides guidelines 
on the Retransmission (RET) technology. 



2 References 

References are either specific (identified by date of publication and/or edition number or version number) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• Non-specific reference may be made only to a complete document or a part thereof and only in the following 
cases: 

if it is accepted that it will be possible to use all future changes of the referenced document for the 
purposes of the referring document; 

for informative references. 

Referenced documents which are not found to be publicly available in the expected location might be found at 
http://docbox.etsi.org/Reference . 

NOTE: While any hyperlinks included in this clause were valid at the time of publication ETSI cannot guarantee 
their long term validity. 

2.1 Normative references 

The following referenced documents are indispensable for the application of the present document. For dated 
references, only the edition cited applies. For non-specific references, the latest edition of the referenced document 
(including any amendments) applies. 

[1] ETSI TS 102 034 (Vl.4.1): "Digital Video Broadcasting (DVB); Transport of MPEG-2 TS Based 

DVB Services over IP Based Networks". 

2.2 Informative references 

The following referenced documents are not essential to the use of the present document but they assist the user with 
regard to a particular subject area. For non-specific references, the latest version of the referenced document (including 
any amendments) applies. 

[i.l] ETSI TR 102 542: "Digital Video Broadcasting (DVB); Guidelines for DVB IP Phase 1 

Handbook" . 

[i.2] ETSI TS 102 542-1: "Digital Video Broadcasting (DVB); Guidelines for the implementation of 

DVB-IPTV Phase 1 specifications; Part 1: Core IPTV Functions". 
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Abbreviations 



For the purposes of the present document, the following abbreviations apply: 

CoD Content on Demand 

DA Destination Address 

DP Destination Port 

DVB Digital Video Broadcasting 

GA Group Address 

HNED Home Network End Device 

IETF Internet Engineering Task Force 

IGMP Internet Group Management Protocol 

LMB Live Media Broadcast 

MBwTM MediaBroadcast with Trick Modes 

MC Multicast 

RET Retransmission 

RTP Real-time Transport Protocol 

RTCP Real-time Transport Control Protocol 

RTCP FB RTCP Feedback 

RTCP FF RTCP Feedforward 

RTCP RR RTCP Receiver Report 

RTCP RSI RTCP Receiver Summary Information 

RTCP SDES RTCP Source description 

RTSP Real Time Streaming Protocol 

SA Source Address 

SDP Session Description Protocol 

SP Source Port 

SSRC Synchronization SouRCe 

UC Unicast 

XML extensible Markup Language 



4 Example of messaging flow involved in DVB RET 

retransmission for LMB services 

DVB retransmission solution for LMB services builds on the DVB RTP retransmission solution for CoD services, but 
has additional flexibilities and parameters, in order to make the solution sufficiently scalable. In this paragraph we show 
an architecture example and related RTP/RTCP message flows for a RET-enabled LMB service from the HNED point 
of view. 

Figure 1 shows the considered example architecture. The Head-end sources the multicast streams (carrying the LMB 
services), which the HNEDs can join by means of the IGMP protocol. The LMB service is RET-enabled and the 
HNEDs have been configured with RET DVB parameters, including network/transport address of the LMB RET 
server(s). In this example an HNED equipped with a DVB RET client can interact with the LMB RET server both in 
unicast and multicast way. From the HNED point of view, three different RTP sessions can be considered: 

1) The original RTP multicast session, in which the Head-end sources the RTP multicast streams. The 
RET-enabled HNED issues in this session the unicast RTCP messages for retransmission requesting (RTCP 
Feedback messages) and for status reporting (RTCP Receiver Reports) to the LMB Retransmission server, 
hosting the RTCP (Feedback) target for the original RTP multicast session (depicted as a dashed line in 
figure 1). 

2) The unicast RTP retransmission session in which the LMB RET server responds to the RTCP retransmission 
requests received from the HNEDs in the original RTP multicast session. In this session, the RET client of the 
HNED may also provide status reporting with respect to the unicast RTP retransmission stream towards the 
LMB RET server. 
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3) There may be optionally also a multicast RTP retransmission stream, which can be used by the LMB RET 
server to address individual network packet loss events in the original RTP multicast session that impact 
multiple HNEDs (packet loss event 1 in figure 1). This dedicated RTP session may not only carry RTP 
retransmissions packets but also RTCP Feedforward messages, which advertise packet loss events with the 
purpose to suppress retransmission requesting. 

NOTE: Such RTCP feedforward message is a unicast RTCP Feedback message from a DVB RET client that is 
relayed by the LMB RET server over the retransmission multicast session towards all DVB RET clients 
downstream from the LMB RET server. This DVB RET client could be an "upstream" client -as depicted 
in the figure 1- or a subset of the HNEDs downstream of the LMB RET server 

The three different sessions are differentiated by means of different transport addresses (IP source and destination 
addresses and ports) and have in general different SSRC identifiers (RTP layer). 



Head End 



Original RTP Multicast 
GroupIP Address = G^ 
Source IP Address =X 
Destination Port = N 
SSRC = A 



I upstream ! 
IRET client! 



(MC) Router! 
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LMB RET 
server 



Retransmission RTP Multicast 
Group IP Address = G2 ^^ 
Source IP Address =Y ^^ 
Destination Port = M 
SSRC = B 

Packet Loss 
Event 1 



Retransmission RTP Unicast 
Destination IP Address = B 
Source IP Address =Y 
Destination Port = P 
SSRC = C 



;(MC) Router; 

I 

A 




Packet Loss 
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RET client 



HNEDA 



v>L 



RET client 



HNEDB 



Figure 4.1 : Architecture example for a RET-enabled LMB service 

The following messaging flows is an illustrative example of the interactions involved in a DVB RET-enabled LMB 
service in which the three RTP sessions as explained above are present. The focus is on RTCP message exchange and 
DVB RET client behaviour. 

The scenario considered is the following: 

• A RET-enabled HNED connects to a LMB service ("channel A") with IGMP, which establishes the original 
RTP multicast session from the HNED point of view. The HNED also connects to the LMB multicast 
retransmission session by means of IGMP. This session connection occurs every time the HNED changes 
channel. When packet loss takes place, this is detected by the RET client in the HNED. In this case this is 
packet loss impacting only one HNED (e.g. the packet loss is caused by a failure on the access link). When the 
HNED requests the retransmission and the LMB RET server responds with a unicast retransmission, the 
retransmission session is established. A second packet loss event takes place downstream of the LMB RET 
server, but now impacts multiple HNEDs. In this case the LMB RET server responds with a retransmission in 
the RTP multicast retransmission session. 



ETSI 



8 ETSI TS 1 02 542-3-3 V1 .3.1 (201 0-01 ) 

• After some time the HNED changes channel (channel B). During the time the HNED receives channel B (in 
the new original multicast session), the HNEDs detects several packet loss events, but all interaction with the 
LMB RET server occurs solely in unicast. 

• After some time the HNED changes channel (channel C). During this session no packet loss events take place 
and there is no interaction with the LMB RET server at all. 

• After some time the HNED changes channel to channel B again. Several packet loss events take place, and the 
last packet loss event in the considered scenario takes place upstream from the LMB RET server that is 
detected by the "upstream retransmission client" entity in the LMB RET server. The LMB RET server relays 
the RTCP Feedforward message in the RTP retransmission multicast session which suppresses the 
retransmission request by the HNED. Once the packet is recovered by the LMB RET server (outside the scope 
of DVB RET), this packet is retransmitted in the multicast RTP retransmission stream. 

More specifically in the considered scenario, some of the DVB RET parameters are configured at the HNED as follows: 

• both a unicast and multicast retransmission service is advertised towards the HNEDs with signalling of all 
transport address related parameters; 

• dvb-t-wait-min (ms) and dvb-t- wait-Max (ms) are configured, meaning that the HNED reports packet loss at a 
random point in time between dvb-t-wait-min and dvb-t- wait-Max upon packet loss detection; 

• dvb-t-ret (ms) is configured, meaning that the HNED can issue a second (third, fourth,..) retransmission 
request after getting no response on the previous retransmission request within the time frame as specified by 
dvb-t-ret; 

• RTCP-Bye is enabled; 

• the HNED is instructed to send RTCP status report messages (RTCP RR) in the original RTP session; 

• the HNED is not allowed to send RTCP status report messages (RTCP RR) in the unicast RTP retransmission 
session. 
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Figure 4.3 

Table 1 describes in more detail the different events and message exchanges for the particular example scenario. 

Table 4.1 : Message exchanges and triggering events for a RET enabled LMB service 
with support for Multicast RTP retransmission (example) 



Time 
(T) 


RTP/RTCP message 
reception/transmission / Event 


HNED timing 


RTP session 
initiation/closure 


1 


IGMPv3 message exchange to join RTP 
original session (channel A) and RTP RET 
MC session (for channel A) 




Original RTP MC 
session and MC RTP 
RET session 
established. 


1 


First RTP packets MC group Ch A received 
(GA=G1 ; SA=X; DP=N/N+1 ; SSRC=A) 






1 


Packet Loss detection by HNED 






1 


RTCP FB message sent by HNED 
(DA=Y; SA=Z; DP=Ma; SP=R, SSRC 
packet sender=Z; SSRC media 
source=A) 


Message sent at 
random point in time 
between 1^+ T^j^ and 
VT.ax;DVB-T-RET 
count-down started 




1 


RTP RET packet received by HNED 
(DA=Z; SA=Y; DP=R; SP=Va, SSRC=T) 


RTP packet is received 
by HNED before 
DVB-T-RET is elapsed 
after T3 


UC RET RTP session 
established. 


" 




(DVB-T-RET now 
elapsed since T3, but 
nothing happens, as 
RET packet received) 




1 


RTCP SDES+RR message sent by HNED 
(DA=Y; SA=Z; DP=Ma; SP=R, SSRC 

packet sender=Z; SSRC media 
source=A) 
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Time 

(T) 


RTP/RTCP message 
reception/transmission / Event 


HNED timing 


RTP session 
initiation/closure 


1 


Packet Loss detection by HNED 






1 


RTCP FB message sent by HNED 
(DA=Y; SA=Z; DP=Ma; SP=R, SSRC 

packet sender=Z; SSRC media 
source=A) 


Message sent At 
random point in time 
between T^ + T^j^ and 

Ty + T^ax; DVB-T-RET 

count down started 




1 


DVB-T-RET elapsed prior to reception of 

missing packet (as original packet or as 

RET packet) or reception of RTCP FF 

message ; RTCP FB message is re-sent by 

HNED 

(DA=Y; SA=Z; DP=Mj^; SP=R, SSRC 

paclcet sender=Z; SSRC media 
source=A) 


DVB-T-RET 
count down started 




■ 


MC RET packet received (= reported 

missing packet) 

(GA=G1r; SA=Y; DP=N; SSRC=A) 


Received before 
DVB T-RET has 
elapsed since Tg 




■ 


End-user zaps to new channel B: IGMPvS 

message exchange to 

-leave MC RTP original session and RTP 

RET MC session (channel A) 

-join RTP original session (channel B) and 

RTP RET MC session (for channel B) 




New Original RTP MC 
session and MC RTP 
RET session 
established. 


■ 


RTCP SDES + Bye Message sent by HNED 
(DA=Y; SA=Z; DP=IVIa; SP=R, SSRC 

paclcet sender=Z; SSRC media 
source=A) 




HNED closes explicitly 
the RTP RET UC 
session. 


m 


First RTP packets MC group Ch B received 
(GA=G2; SA=X; DP=N/N+1 ; SSRC=B) 






m 


Packet Loss detection by HNED 






m 


RTCP FB message sent by HNED 
(DA=Y; SA=Z; DP=IVIb; SP=R, SSRC 
paclcet sender=Z; SSRC media 
source=B) 


Message sent at 
random point in time 
between T^4 + T^jn and 
Ti4 + T,ax; DVB T-RET 
count down started 




13. 


RTP RET packet received by HNED 
(DA=Z; SA=Y; DP=R; SP=Vb, SSRC=T) 


RTP packet is received 
by HNED before 
DVB T-RET is elapsed 
after T^ 5 


Unicast RTP RET 
session established. 


17 


RTCP SDES+RR message sent by HNED 
(DA=Y; SA=Z; DP=Mb; SP=R, SSRC 

packet sender=Z; SSRC media 
source=B) 






18 


Packet Loss detection by HNED 






19 


RTCP FB message sent by HNED 
(DA=Y; SA=Z; DP=Mb; SP=R, SSRC 

packet sender=Z; SSRC media 
source=B) 


Message sent At 
random point in time 

between T^ 8+ "'"min^'^d 
Tl8+T,ax; DVB T-RET 

count down started 




20 


End-user zaps to new channel C: IGMPvS 

message exchange to 

-leave RTP original session and RTP RET 

MC session (channel B) 

-join RTP original session (channel B) and 

RTP RET MC session (for channel C) 




New Original RTP MC 
session and MC RTP 
RET session 
established. 


21 


RTCP SDES + Bye Message sent by HNED 
(DA=Y; SA=Z; DP=Mb; SP=R, SSRC 

packet sender=Z; SSRC media 
source=B) 




HNED closes explicitly 
the RTP RET UC 
session. 
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Time 

(T) 


RTP/RTCP message 
reception/transmission / Event 


HNED timing 


RTP session 
initiation/closure 


22 


First RTP packets MC group Ch C received 
(GA=G3; SA=X; DP=N/N+1 ; SSRC=C) 






22 


End-user zaps to channel B: IGMPvS 

message exchange to 

-leave RTP original session and RTP RET 

MC session (channel C) 

-join RTP original session (channel B) and 

RTP RET MC session (for channel B) 




Unicast RTP RET 
session for channel C 
was never established! 
New Original RTP MC 
session and MC RTP 
RET session 
established 


24 


First RTP packets MC group Ch B received 
(GA=G2; SA=X; DP=N/N+1 ; SSRC=C) 






25 


Packet Loss detection by HNED 






26 


RTCP FB message sent by HNED 
(DA=Y; SA=Z; DP=Mb; SP=R, SSRC 

packet sender=Z; SSRC media 
source=B) 


Message sent at 
random point in time 
between T25+ T^j^ and 

T25+T,ax;DVBT-RET 

count down started 




27 


RTP RET packet received by HNED 
(DA=Z; SA=Y; DP=R; SP=Vb, SSRC=T) 


RTP packet is received 
by HNED before 
DVB T-RET is elapsed 
after T26 


Unicast RTP RET 
session established. 


28 


Packet Loss detection by HNED (and by 
LMB RET server) 






29 


RTCP FB message sent by HNED 
(DA=Y; SA=Z; DP=IVIb; SP=R, SSRC 

paci^et sender=Z; SSRC media 
source=B) 


Message sent at 
random point in time 
between T28+ T^j, and 
T28+T,,,; DVB T-RET 
count down started 




30 


Reception of RTCP FF message (GA=G2p; 
SA=Y;DP=N;SSRC=B) 


Before DVB-T-RET was 

elapsed since T29; 

DVB-T-RET 

count down re-started 




31 


Reception of RTCP MC RET packet 
(GA=G2r; SA=Y; DP=N; SSRC=B) 


Reported missing 
packet received , 
before DVB-T-RET was 
elapsed since T30 





5 HNED RET parameter configuration via SDP 

The DVB RET-related parameters can be signalled to the HNED with XML, which is done either via Broadcast 
Discovery records ([1] clause 5.2.6.2 for LMB services) or by means of XML descriptions transmitted with RTSP 
ANNOUNCE method or RTSP DESCRIBE method response (for RTSP cHents of LMB services or CoD/MBwTM 
services). The DVB RTSP client is required to support the reception of descriptions in XML format but additionally, a 
DVB RTSP client supporting DVB retransmission, should also understand session descriptions in SDP format. 

This section contains an example of an SDP description for a RET-enabled CoD and an example of an SDP description 
for a RET-enabled LMB RTP session. They include the RET relevant parameters/attributes including the ones defined 
in the various IETF references for DVB RET, but the focus is here on how to embed those RET parameters defined 
specifically (and exclusively) in the DVB handbook in an SDP description. 

More specifically, the DVB -specific parameter "dvb-t-ret" is a format- specific parameter that can only be specified in 
the m-line associated with the original RTP packet flow and "dvb-disable-rtcp-rr" is a DVB -specific attribute that can 
be specified in SDP per c-line or per m-line both for the original RTP and the unicast retransmission RTP flows. 

The parameter "dvb-t-ret" and attribute "dvb-disable-rtcp-rr" can be included in the SDP file both for LMB and for CoD 
services. Additionally, for RET-enabled LMB services the following DVB media- specific parameters may be included 
in the SDP file in the m-line associated with the original RTP session: "dvb-t-wait-min", "dvb-t-wait-max", 
"dvb-ssrc-bitmask", "dvb-ssrc-upstream-client", "dvb-rsi-mc-ret" and "dvb-enable-bye". 
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5.1 SDP example for RET-enabled CoD 

The SDP example for the RET-enabled COD service describes a SSRC multiplexing scheme. In the given example, the 
HNED must not issue RTCP RR reports both with respect to the Retransmission and Original RTF packet flows. The 
original packets are buffered for 1 second, and there should be at least 300 ms between two consecutive RTCP FB 
messages requesting retransmission for the same packet. The bandwidth that can be maximum consumed by the HNED 
for its RTCP (FB) reporting is 50 kb/s. 

v=0 

o=dvb-iptv-service-provider-x 2980675221 2980675778 IN IP4 dvb-iptv-service-provider-x. cod-service- 

y-with-ret . com 

c=IN IP4 192.0.2.0 

a=dvb-di sable -rtcp-rr 

m=video 49170 RTP/AVPF 33 96 

a=rtpmap:33 MP2T/90000 

a=ssrc : 123321 cname : cod-server-89@dvb-iptv-service-provider-x. com 

a=rtcp-fb:33 nack 

a=fmtp:33 dvb-t-ret=300 

b=RR:50 

a=rtpmap:96 rtx/90000 

a=ssrc : 232345 cname : cod-server-89@dvb-iptv-service-provider-x. com 

a=fmtp:96 apt=33 ; rtx-time=1000 



5.2 SDP example for RET-enabled LMB 

The SDP example for the RET-enabled LMB service describes a session multiplexing scheme in which retransmissions 
can be sent both unicast and multicast mode. In the given example, the HNED can send in the original session RTCP 
FB messages in stand-alone (non-compound) mode. The original packets are buffered for 1 second by the LMB RET 
server, and there should be at least 300 ms between two consecutive RTCP FB messages requesting retransmission for 
the same packet. The HNED must respect a waiting time of 200 ms before issuing an RTCP FB message upon packet 
loss detection, unless it is an early reporter, for which the "dvb-ssrc-bitmask" is signalled. The HNED is expected to 
issue the RTCP bye in the original RTP session when applicable. In the retransmission flow the RTP and RTCP packets 
are multiplexed on the same port. The HNED is expected to issue RTCP RR reports in the retransmission session. The 
bandwidth that can be consumed by the HNED for its RTCP reporting is 5 % of the original stream bandwidth (default 
value, not signalled). The RTCP RSI messages pertaining to the original MC RTP session are distributed in the MC 
retransmission RTP session. 

v=0 

o=dvb-iptv-service-provider-x 2980675221 2980675778 IN IP4 dvb-iptv-service-provider-x. lmb--service- 

z-with-ret . com 

a=rtcp-unicast : rsi 

m=video 4 0000 RTP/AVPF 3 3 

C=IN IP4 224.1.1.1/255 

a=source-filter:incl IN IP4 224.1.1.1 8.166.1.1 

a=ssrc : 123400 cname :head-end-01@dvb-iptv-service-provider-x. com 

a=recvonly 

a=rtpmap:33 MP2T/90000 

a=rtcp:40001 IN IP4 9.30.30.1 

a=rtcp-fb:33 nack 

a=rtcp-rsize 

a=fmtp : 33 dvb-t-ret=400 ;dvb-t-wait-min=200 ;dvb-t-wait-max=200 ;dvb-ssrc-bitmask=3 ;dvb-ssrc-upstream- 

client=123401 ;dvb-rsi-mc-ret ;dvb- enable -bye 

m=video 10000 RTP/AVPF 97 

c=IN IP4 9.30.30.1 

a=ssrc : 123800 cname : ret-server-02@dvb-iptv-service-provider-x. com 

a=recvonly 

a=rtpmap:97 rtx/90000 

a=fmtp: 97 apt=33 ; rtx-time=1000 ; 

a=rtcp-mux 

m=video 50000 RTP/AVPF 98 

C=IN IP4 224.1.1.1/255 

a=source-filter:incl IN IP4 224.1.1.1 8.166.1.5 

a=recvonly 

a=rtpmap: 98 apt=33 ; rtx-time=1000 

a=dvb- disable -rtcp-rr 
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